今天將要開始介紹RAG的基礎組成元素：Chunks，進行RAG的時候最重要的就是「找到」可以幫助LLM回答的資訊。那你可能會想說那為什麼不要直接將文件完整的一份一份轉換成向量之後存放起來就好，這樣就可以完整包涵到必要的資訊在裡面了！
可是實際上真正與問題相關的資訊只占據文件的一部分，多找出來的資訊不僅都回答不到使用者問題，還會造成系統上的負載過重。另外一個原因就是成本問題，因為檢索出來的資料會一起傳給LLM去做參考，這些參考資料都是需要花費tokens，tokens愈多每次問答的成本自然愈高。

因此在將文章進行切割就會是一大學問，要確保切割的每段長度適中，且並不會造成事後檢索的時後造成tokens使用過多等等問題。目前我查到比較多人在討論的相關切割chunks的方法大約有以下幾種

1. 固定大小：
   直接規定每一個chunks僅包含多少個tokens，但是這個概念一定套用不到中文上。原因很簡單：中文並非都是由一個token所代表，一個中文字可能由兩到三個來表示。所以如果好死不死切割的位置在中文字上，這樣會造成儲存出錯。

2. 循環切割
   這個方式有點像由大到小逐漸去切斷，可能會先大段落的切，接著在深究一個段落中去切割成小段落或者句子。實際上是如何由大到小就會依照不同的方法而有所不同，若第一次切割的標準超過長度限制，那就會重新用新的標準去切，直到最終符合長度要求。

3. 基於段落切割
   遵照文章的架構去切，但是這種方法對資料的要求可能就會比較高。畢竟如果段落不明確的文章會太難判斷哪兩行字之間是屬於不同段，所以使用此方法會建議要是段落明確的資料，可能像是規章資料。

4. 語意分割
   顧名思義，此方法就是要先語意理解然後再去切。這個方法想必需要利用其他種小規模或者相對ChatGPT那樣小一點規模的LLM來幫助語意理解，接著再去依照理解結過去分開被判斷是不一樣意思的段落。

   總之切割的方式百百種，想要有最好的檢索素材就會需要去調教符合自己素材的切割方式。後來有找到一個github開源的chunks評估系統，有興趣的朋友可以點擊來看看。明天將會提供一些實作切割的分享，如果想要做一套有關資料檢索的專案聊天機器人，或許就可以用這個方法來建構出你們想要的機器人！